Clarify maintainers' duties #193
Conversation
Signed-off-by: Luís Cobucci <[email protected]>
This restructures the document to add details on what we expect maintainers to do and the minimum requirements to become a maintainer. Signed-off-by: Luís Cobucci <[email protected]>
|
|
||
| To become a maintainer, you must first have another maintainer or a TSC member nominate you to the TSC. | ||
| Nominations are done by submitting an issue to this repository with a title prefix of `[NOMINATION][MAINTAINER]` (or select the "Maintainer Nomination" issue type when creating an issue on this repository). | ||
| Maintainers are approved by a majority vote of the TSC, which will be held no later than 1 week following the nomination. |
There was a problem hiding this comment.
Is this 1 week following the nomination still correct?
There was a problem hiding this comment.
IMO, we should change this to "the next monthly TSC meeting". An async vote, even if opened within a week would still take longer to gain the required votes, so it makes more sense to announce and start the vote at the meeting.
|
|
||
| ### Requirements | ||
|
|
||
| - Consistent high-quality contributions (code changes, reviews, discussions, etc) over time |
There was a problem hiding this comment.
Can we make "over time" a little more explicit?
There was a problem hiding this comment.
Who evaluates that contributions are of "high-quality"? Should it be the nominator's duty to validate that before submitting the nomination?
There was a problem hiding this comment.
It would be nice to know in advance that they will not quit after one month but you cannot expect fidelity. No one can expect fidelity of any employee in any company, so even less from volunteers in an OSS project.
However, a track record of contributions, consistent over time, would give a good warm and fuzzy feeling that the person would stick around.
I propose the following language:
- Consistent high-quality contributions (code changes, reviews, discussions, etc) on a regular basis
| ### Requirements | ||
|
|
||
| - Consistent high-quality contributions (code changes, reviews, discussions, etc) over time | ||
| - Demonstrated understanding of project goals and coding standards |
There was a problem hiding this comment.
Isn't adherence to coding standards enforced via phpcs in the CI checks?
Are the project goals defined somewhere?
There was a problem hiding this comment.
Not necessarily, coding standards can be related to design principles and values (which aren't always enforceable by tooling).
Would you have a better phrasing for this?
There was a problem hiding this comment.
Not really.
As a requirement, it makes sense as is. I think this is where the nominator should review the previous work of the nominee to ensure quality and adherence to standards and goals. Nominators should consult with other maintainers where the nominee's work has been reviewed, merged, etc. to get their feedback. There are not too many ways to assess the nominee's work and it would be based on judgement in the same way a supervisor would assess a subordinate's work.
|
|
||
| Beyond driving fixes/improvements, we expect maintainers to: | ||
|
|
||
| - Ensure project continuity, quality, and consistency |
There was a problem hiding this comment.
One thing mention in the TSC meeting was the expectation that maintainers would commit themselves to be around.
So I propose to change this requirement to:
- Be committed to the project to ensure its continuity, quality, and consistency
| - Consistent high-quality contributions (code changes, reviews, discussions, etc) over time | ||
| - Demonstrated understanding of project goals and coding standards | ||
| - Active participation in discussions and issue resolution | ||
|
|
There was a problem hiding this comment.
I would also add:
- Demonstrated understanding of the contribution guidelines, such as well documented commits and pull requests, semantice versioning, etc.
- Demonstrated understanding of the automated processes (continuous integration, automatic releases)
Description
This restructures the document to add details on what we expect maintainers to do and the minimum requirements to become a maintainer.